Use Schema to make frontend generic (part 1) #154
Conversation
There's already an effect to handle this
|
Nice work with the simplification! Could you comment on what is still required in the JSON file at the moment and what we need? Judging from the "Import Posts" button, one thing that we need is a plural term in the schema (see get_post_type_labels()), I also tried to rename the |
|
Great point about the plurals @akirk, opened #158 to tackle that. Also, great catch (thanks!) with the error that shows after renaming the title, opened #159 for that one.
I'm not sure I understand what you mean by this. Do you mean whether there are still properties missing in the schema that we would need, and/or whether there are properties that are already in the schema that we are not leveraging? (I opened #157 which is related to this) I created tickets for all things mentioned here and others I could think of, linked them as sub-tickets of #137, and also added them to the milestone. |
psrpinto
changed the title
This is a partial fix for #137
Everything should still function, this is just refactoring.
This PR makes it so that the frontend uses the schema to determine what fields a subject has. It's mostly all cherry-picked from #132 with slight changes.
The frontend code has been (almost, see Next Steps below) fully adapted to use the schemas, which means that the code is now generic. All the specific types (
BlogPost,Page,BlogPostBlueprint, etc) have been removed, and the only types left are generic (Subject,Blueprint).This results in the code being massively simplified, and adding a new subject type does no longer require changing a bunch of files, and copy-pasting code around.
A new
SubjectsApihas also been introduced, and the specificBlogPostsApiandPagesApiwere removed. However, internally,SubjectsApi, still differentiates between subject types because it needs to call different endpoints depending on the subject type.Next steps
See sub-issues in #137